Cross-site Scripting(XSS)
Cross-site Scripting,俗稱XSS。我們一般使用者看到的網站是由前端的HTML加Script,CSS所組成，而網站的功能則是由後端來實現，這邊的後端指的是像是Python的Flex框架或是Google Edge的Gene框架,或是Node.js,或是PHP等等的。那跟很多的Web Attack一樣，XSS也是因為使用者的輸入或是正確判斷檢查等等的原因，才導致這種弱點的發生。
在網站提供使用者可以互動的地方都可能有類似的漏洞，最常發生的狀況就是所謂的搜尋框。我們可以想像一種情境，例如說一個Google搜尋框，當你搜尋按下去之後，它會跳到另外一個頁面,或是有一個result會給你，上面也會帶著你剛剛輸入的,假設你剛剛輸入的123，它也會在網站上顯示123。那如果這時候你在這個輸入框裡面輸入一個JavaScript的語法或是一個HTML語法，那它就有可能在解析的時候因為解析不正確的關係，去執行了JavaScript中的內容，或是執行了HTML裡面的tag這樣子。
那我們先看一個簡單的範例。這邊有兩個檔案，一個是index.html,
<input type='text' id="Input">
<button id="Button">Submit</button>
<p>
Hello <span id="Name"></span>
</p>
然後下面有一個test.js。
const Input = document.querySelector('#Input')
const Button = document.querySelector('#Button')
const Name = document.querySelector('#Name')
Button.addEventListener('click', () => {
Name.innerHTML = Input.value;
})
html實際網頁:
在index.html那邊我們可以看到這邊有一個inputs的type是text，然後這邊有一個button。text它做的事情很簡單，就是有一個input然後一個button，當我們輸入的時候它就會把這個值帶進去。也就是說如果當我們輸入一個hacker的時候，它會給我們一個hello hacker。但如果我們輸入JavaScript或是HTML語法的時候，會因為解析的關係自動把它帶進去。
我們今天如果用一個H1的tag裡面寫一個root，那它在解析的時候就把它當成一個完整的HTML語法，就把它當成一個大標題做顯示，那這個基本上就是一個我們叫反射式XSS，也就是reflect XSS。
原價屋的話它就有類似這種漏洞，那這個是已經完成通報並且那邊已經有修補了。
原價屋Cross-Site Scripting - HITCON ZeroDay
基本上也算很簡單的一個漏洞，它的漏洞產生的地方，是在email或是用手機電話查詢欄位裡面，它輸入一個雙引號然後大於，就可以發現說未過濾資源，並將原本的雙引號跟大於擠掉。第一次修補的時候有針對資源做限制，例如說電話號碼不能輸整數以外的資源，但因為它這個只做前端的防護，所以可以使用Burp Suite繞過。
我們在email留空，然後在test.fmt這個欄位裡面輸入先用一個雙引號再一個小括號，後面接一個一串JavaScript的語法，就是script alert xss，送出去之後它就會response成這個頁面。
再來是另外一個store xss。一般會認為說儲存式的xss比反射式更具威脅，因為可能會導致在瀏覽同一網站的用戶都受影響。大概在十幾年前留言板盛行的時期，就有很多留言板因為對使用者輸入的留言沒有做管控，甚至它本身那個留言的editor就支援了部分的一些HTML語法，但是又沒有過濾JavaScript，導致查看留言板的人都會自動跳轉到惡意網站。
因為這樣的原因，一般使用者在不知情的狀況下把自己的cookie送給了別人。有一個很簡單的想法是，我們在上面那個request最下面的script這邊裡面插一個HTML request，然後發送Document Cookie到某一個domain裡面。那在攻擊者那邊他只要開了一個web服務，他就會收到來自於那個受害者這邊的Document Cookie，然後可能是接在這個path後面。它可能是一個Base64串起來的一個cookie，那攻擊者只要把這串Base64給decode之後，就會看到這個cookie然後做到帳戶接管，在無密碼的狀況下可以進行登入動作。
基本上這個原理跟Reflex XSS相同，區別只在於說網站提供的功能會將這個資料儲存下來，然後持續的提供在網站內容上。所以只要有人瀏覽到相同的留言板就會中招。
一般會認為說XSS在PT中比較不常見，或是說比較少用這個手段做出發點，但在某些狀況下很好用。曾經有一個案例是市場客服系統，Bot收到來自使用者的Document然後讀取內容觸發XSS。另外，XSS觸發並不只在明面上的使用者輸入，有時也會讀取Request Header，作為網站動態生成內容的一部分。
例如說在某一個案例裡面，它為了辨別這個使用者是使用Apple OSX裝置、IOS裝置、Android裝置或是使用Chrome等等的，那它把User Agent還有其他的Header放進了這個網站的生成內容中。所以當你登入的時候就會顯示你現在是使用什麼樣的裝置。把Request攔截下來之後修改了那部分的Header，把它修改成一段XSS的內容，就會引發這樣的漏洞。也有看過說在個人資料裡面的欄位，在一個個人簡介的地方你可以輸入XSS的語法，那只要有瀏覽到你這個個人資料的人都會中招這樣子。
那雖然OSCP它基本上都在考PenTest，Client-side這種XSS部分比較少，不過我之前在打他們的題目的時候，也有遇到過需要用XSS觸發的漏洞。那簡單來說它是有一個Admin Bot，像一個客服管理員這樣子，那它會自動去點擊你給它的Link，但是僅限於它的Domain底下的網址。所以會先在那個網站上找到一個XSS，然後你要去偷取這個Bot，也就是那個Admin的Cookie，然後依此登入那個網站再做後續的利用這樣子。當然也可以做釣魚使用，畢竟它來自於一個合法的網站，也會比較被人家信任。
